app: extract the create backup usecase - #1205

Part of #1171

What

app gains the CreateBackup usecase: one struct holding the config, the two storage clients, the task manager and the backup root path, constructor-built from config. The action is create a backup job: a job is what a create call makes, and the backup artifact is what a successful job leaves behind — the two-resource split of the v2 API (#1124), where jobs/backup/create returns the job and backups/describe reads the artifact.

• Start(req) is the synchronous act of starting a job — it assembles backup.TaskArgs and calls backup.NewTask, which registers the job in the task manager, and returns the registered job ready to run behind a small BackupJob interface
• Execute(ctx, req) runs the job synchronously and answers with the task manager's view of it: id, state, progress and the rest of the job half — the shape v2's jobs/backup/create responds with. It never reads the persisted meta; a transport whose contract merges the two resources (v1) assembles what it needs itself

Both transports call it:

• the create CLI command (cmd/create) builds app.NewCreateBackup + Execute; flag parsing, name defaulting, validation and the printed output stay in cmd
• the /api/v1/create handler (core/server) renders the pb request into app.CreateBackupRequest — keeping the deprecated pb fields (db_collections, collection_names, force, meta_only), name validation and the error-to-code mapping — through a newCreateBackup constructor hook on the server config that tests stub out, the same seam list and delete got in app: extract the list backups usecase #1182 and app: extract the delete backup usecase #1200
• the v1 async flag stays a server concern: the handler calls Start and spawns the goroutine itself (unchanged logging on failure), while taskmgr registration stays where it was, inside backup.NewTask. core/backup is not touched
• NewCreateBackup takes the task manager as a parameter instead of reading taskmgr.DefaultMgr() itself; cmd/create and the server wiring pass the process-local manager, keeping the global reference out of the usecase layer

Rebased on top of the config fork (#1215): the v1 backup_root_path field is applied as a config override, not a request field. The handler forks the loaded config with backup.storage.rootPath as one more override layer — the same move get_backup makes for its path parameter in #1203 — and the forked params are what NewCreateBackup builds the usecase from, so CreateBackupRequest carries no root path and the usecase reads it from its params. The fork is reload-equivalent, so unset backup.storage leaves still cascade from milvus.storage, and the server's own config is never mutated. The artifact directory for a given request is the same as before the rebase.

Semantics unchanged

The v1 wire shape is kept, including its quirks:

• the sync success response still carries only code and msg — no payload and no request_id. The usecase now answers with the job view alone, and the v1 contract needs nothing from it, so the handler discards it; anything a v1 response does need, the handler assembles itself
• request_id defaulting, error-to-code mapping (Parameter_Error for a bad name, Fail for everything else, request_id echoed on failures), filter/strategy/format precedence and the deprecated-field fallbacks are unchanged
• async behavior is unchanged: same response message (create backup is executing asynchronously), same request_id echo, task still registered synchronously in the default task manager before the goroutine starts

Two pre-existing bugs were found and are not fixed here:

• empty backup_name still panics in backup.ValidateName and lands on gin's recovery as a 500, exactly as before

Two deliberate behavioral deltas, both limited to error paths:

• the sync path used to fall through from a backup.NewTask error into task.Execute on a nil task — a guaranteed panic. The usecase returns that error instead, so a job whose registration fails now answers Fail with the error message
• the old sync path read the task view, the persisted meta and the meta size after a successful run and answered Fail when any of those reads failed — even though the backup had already succeeded — all to build a brief it then discarded. That read only ever fed the discarded payload, so it is gone together with the payload: a successful backup now always answers success

Tests

• app/create_test.go: Start registers the job in the task manager and refuses a second live job for the same backup name; Execute propagates the start failure; the artifact dir is the configured root path plus the option's name
• core/server/create_test.go: httptest cases over the handler contract — sync runs through the usecase and the success response carries no payload (quirk pinned), request_id generated and forwarded, invalid name rejected with Parameter_Error before the usecase runs, constructor/build/execute/start errors mapped to Fail, async starts the job and returns immediately, backup_root_path forks the loaded config while the server's own config stays on the default root path (and without the field the config travels to the usecase untouched); plus the pb→option rendering incl. deprecated force/meta_only and the three filter sources